5.4 Mathe bitte strikt 

Bei der Berechnung mit Fließkommazahlen schreibt die Definition des IEEE-754-Standards vor, wie numerische Berechnungen durchgeführt werden. Damit soll die CPU/FPU für float und double mit 32 beziehungsweise 64 Bit rechnen. In Wirklichkeit rechnet jedoch so gut wie kein mathematischer Prozessor mit diesen Größen, außer vielleicht AMD mit der 3Dnow!-Technologie. Auf der PC-Seite kommen Intel und AMD mit internen Rechengenauigkeiten von 80 Bit, also zehn Byte, zum Zuge. Dieses Dilemma betrifft aber nur 80x86- und andere CISC-Prozessoren. Bei RISC sind 32 Bit und 64 Bit das Übliche. Die 80-Bit-Lösung bringt in Java zwei Nachteile mit sich:

• Diese Genauigkeit kann Java bisher nicht nutzen.

• Wegen der starren IEEE-754-Spezifikation kann der Prozessor weniger Optimierungen durchführen, weil er sich immer eng an die Norm halten muss. Das kostet Zeit. Gegebenenfalls können aber die mathematischen Ergebnisse auf unterschiedlichen Maschinen anders aussehen.

5.4.1 Strikt Fließkomma mit strictfp 

Damit zum einen die Vorgaben der Norm erfüllt werden und zum anderen die Geschwindigkeit gewährleistet werden kann, lässt sich vor Klassen und Methoden der Modifizierer strictfp setzen, damit Operationen strikt nach der IEEE-Norm vorgehen. Ohne dieses Schlüsselwort (wie es also für unsere meisten Programme der Fall ist) nimmt die JVM eine interne Optimierung vor. Nach außen bleiben die Datentypen 32 Bit und 64 Bit lang, das heißt, bei den Konstanten in double und float ändert sich nichts. Zwischenergebnisse bei Fließkommaberechnungen werden aber eventuell mit höherer Genauigkeit berechnet.

5.4.2 Die Klassen Math und StrictMath 

Für strikte mathematische Operationen hat Sun die Klasse StrictMath deklariert. An der Klassendeklaration für StrictMath lässt sich ablesen, dass alle Methoden sich an die IEEE-Norm halten.

public final strictfp class StrictMath { 
 // ... 
}

Allerdings ist es so, dass es keine zwei Implementierungen der mathematischen Funktionen gibt – einmal strikt und genau beziehungsweise einmal nicht strikt, dafür potenziell schneller. Bisher delegiert die Implementierung für Math direkt an StrictMath.

public final strictfp class Math 
{ 
  public static double tan( double a ) { 
    return StrictMath.tan( a ); 
    // default impl. delegates to StrictMath 
  } 
  // ... 
}

Die Konsequenz ist, dass alle Funktionen wie Math.pow() strikt nach IEEE-Norm rechnen. Das ist zwar aus Sicht der Präzision und Übertragbarkeit der Ergebnisse wünschenswert, aber die Performance ist nicht optimal.